If a database transaction is specified to be an atomic transaction, then the effect of that transaction on a database must either be entirely complete if that transaction succeeds, or entirely absent if that transaction fails. A partial effect is unsatisfactory. A single atomic transaction may affect multiple databases. At the conclusion of such a transaction, a commit instruction is sent by a transaction manager to each of the databases affected by that transaction. It is possible for the commit instruction to succeed relative to one of these databases but to fail relative to another of these databases. Because the transaction is specified to be an atomic transaction, the effect of the transaction relative to all databases must be rolled back whenever the transaction fails relative to any database.
Therefore, when a commit instruction of an atomic transaction fails relative to a certain database, a database driver associated with that certain database should responsively send a failure signal to the transaction manager. Upon receiving the failure signal, the transaction manager should responsively send a rollback instruction to database drivers associated with each of the other databases affected by the transaction. Upon receiving the rollback instruction, a database driver should perform a rollback operation relative to that driver's associated database. The rollback operation should cause the effects of the transaction relative to that database to be negated; in other words, after the rollback operation, that database should include only data included in that database prior to the start of the transaction.
One approach to testing whether the rollback operation was actually performed after a transaction failed involves inducing an actual failure relative to one of the databases whose driver receives the commit instruction. Inducing an actual failure may cause erroneous data to be contained in that database. Inducing an actual failure may also cause the driver associated with that database to end execution. When that database and its associated driver are concurrently involved in other transactions unrelated to the testing, those other transactions may be adversely affected. Furthermore, inducing an actual failure may require modification of the database driver, which may be time-consuming and may introduce errors into the database driver. Where several multiple-database environments are to be tested, modifications made to a database driver in one environment may not be portable to different database drivers in other environments.